간이 우편 전송 프로토콜

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

간이 우편 전송 프로토콜(SMTP)은 인터넷에서 이메일을 전송하기 위한 표준 프로토콜이다. 1980년에 처음 제안되었으며, 여러 차례의 개정을 거쳐 현재의 모습을 갖추었다. SMTP는 메일 서버 간의 통신뿐만 아니라, 이메일 클라이언트에서 메일 서버로 메일을 전송할 때에도 사용된다. 초기에는 보안 문제와 텍스트 기반의 제약이 있었으나, MIME과 같은 기술을 통해 확장되었고, SMTP 인증, STARTTLS, ESMTP 등의 확장 기능을 통해 보안과 기능을 강화했다. 오늘날 SMTP는 스팸 및 스푸핑에 대응하기 위해 다양한 보안 기술을 사용하며, 아웃바운드 메일 서버 접근 제한과 포트 사용에 대한 정책을 가지고 있다.

더 읽어볼만한 페이지

인터넷 메일 프로토콜 - 포스트 오피스 프로토콜
포스트 오피스 프로토콜(POP)은 이메일 클라이언트가 서버에서 이메일을 다운로드하는 데 사용되는 인터넷 프로토콜로, 보안 강화를 위해 SASL 인증, TLS 암호화 등의 방법이 사용되지만 폴더 관리나 메시지 상태 추적 기능은 제한적이다.
인터넷 메일 프로토콜 - 인터넷 메시지 접속 프로토콜
인터넷 메시지 접속 프로토콜(IMAP)은 이메일을 서버에 저장하고 여러 기기에서 동기화하여 접근할 수 있도록 하는 프로토콜로, POP3에 비해 다양한 장점을 가지며 IMAPS와 STARTTLS를 통해 보안 연결을 지원하고 널리 사용된다.

간이 우편 전송 프로토콜
Simple Mail Transfer Protocol
약어	SMTP
목적	전자 메일 전송 프로토콜
날짜	1981년 11월
OSI 모델	응용 계층
포트	587, 465, 25
RFC	RFC 788, RFC 821, RFC 974
인터넷 프로토콜 스택
응용 계층
프로토콜	BGP DHCP DNS FTP HTTP IMAP IRC LDAP MGCP MQTT NNTP NTP SNTP TIME POP RIP OSPF ONC RPC RTP SIP SMTP SNMP SSH 텔넷 TFTP TLS/SSL XMPP
전송 계층
프로토콜	TCP UDP DCCP SCTP RSVP QUIC
인터넷 계층
프로토콜	IP IPv4 IPv6 ICMP ICMPv6 NDP IGMP IPsec
링크 계층
프로토콜	ARP SPB 터널링 L2TP PPP MAC 이더넷 IEEE 802.11 DSL ISDN

2. 역사

SMTP는 1980년 9월 IETF RFC 772에서 메일 전송 프로토콜(Mail Transfer Protocol)이라는 명칭으로 제안되었고, 두 차례의 개정을 거쳐 1982년 8월 IETF RFC 821/STD0010^[56]으로 표준이 되었다. 이때 간이 메일 전송 프로토콜(SMTP)로 이름이 변경되었다.

이후 2001년 4월에 SMTP는 다른 RFC의 내용도 포함하여 개정되어 IETF RFC 2821^[57]로 제안 표준(Proposed Standard)이 되었다. 이는 인터넷의 보급에 따라 다양한 이메일 확장 기능이 구현되고, 이를 뒷받침하는 부분을 정리할 필요가 있었기 때문이다. 서버 외부로부터의 공격이나 IPv6 주소에도 대응할 수 있도록, 또한 발신자 정책 프레임워크(SPF, IETF RFC 4408), 도메인키 식별 메일(DKIM, IETF RFC 4871) 등에도 대응하기 위해 2008년 10월에 다시 개정(IETF RFC 5321)^[57]되었다.

SMTP는 원래 텍스트 기반 프로토콜이며, 모든 요청/응답 메시지와 메일 데이터가 7비트 ASCII여야 한다는 제한이 있었다. 그러나 영어 이외의 언어나 바이너리 파일을 처리해야 할 필요성이 있어, 이메일에 MIME이라는 표준이 추가되었고, SMTP 자체에도 8비트로 전송하는 확장이 표준화되었다.

2. 1. SMTP 이전의 기술

1960년대에는 여러 형태의 일대일 전자 메시징이 사용되었다. 사용자들은 특정 메인프레임 컴퓨터를 위해 개발된 시스템을 사용하여 통신했다. 특히 미국 정부의 아르파넷에서 더 많은 컴퓨터가 상호 연결됨에 따라 서로 다른 운영 체제 간의 메시지 교환을 허용하는 표준이 개발되었다.

아르파넷의 이메일은 1971년으로 거슬러 올라간다. 구현되지는 않았지만 에 설명되어 있는 메일 박스 프로토콜^[1]과, BBN의 레이 톰린슨이 그 해에 아르파넷의 두 대의 컴퓨터 간에 메시지를 보내도록 개조한 SNDMSG 프로그램^[2]^[3]^[4]이 있다. 1973년 6월 RFC 524에서 메일 프로토콜에 대한 추가 제안이 있었지만,^[5] 이 또한 구현되지는 않았다.^[6]

1973년 3월 RFC 469에서는 아르파넷에서 "네트워크 메일"에 파일 전송 프로토콜(FTP)을 사용하는 것이 제안되었다.^[7] RFC 561, RFC 680, RFC 724, 그리고 마침내 1977년 11월 RFC 733을 통해 FTP 메일 서버를 사용하는 "전자 메일"을 위한 표준화된 프레임워크가 개발되었다.^[8]^[9]

SMTP는 1970년대에 개발된 이러한 표준에서 발전했다. 레이 톰린슨은 1974년 9월 작성된 ''INWG Protocol note 2''에서 국제 네트워크 작업 그룹 간의 네트워크 메일을 논의했다.^[10] INWG는 1979년에 전자 메일을 위한 프로토콜을 논의했는데,^[11] 이는 존 포스텔이 인터넷 이메일에 관한 초기 작업에서 참조했다. 포스텔은 1979년에 인터넷 실험 노트(IEN) 시리즈의 일부로 최초의 인터넷 메시지 프로토콜을 제안했다.^[12]^[13]^[14]

2. 2. 초기 SMTP

1980년, 존 포스텔(Jon Postel)과 수잔 슬루이저(Suzanne Sluizer)는 메일 전송 프로토콜(MTP)을 FTP의 메일 전송 대안으로 제안했다. 1981년 11월, 포스텔은 "간편 메일 전송 프로토콜(Simple Mail Transfer Protocol)"을 발표했다.

센드메일은 1983년 4.1cBSD와 함께 출시되었는데, SMTP를 구현한 최초의 메일 전송 에이전트 중 하나였다.^[19]

2. 3. 현대 SMTP

1995년 11월, 인터넷 표준화 기구(IETF)는 확장된 간이 메일 전송 프로토콜(ESMTP)을 정의했는데, 이는 원래 SMTP에 부족했던 기능을 추가하기 위한 모든 기존 및 향후 확장에 대한 일반적인 구조를 확립했다. ESMTP는 ESMTP 클라이언트와 서버를 식별하고 서버가 지원하는 확장 기능을 나타낼 수 있는 일관되고 관리 가능한 방법을 정의한다.

메시지 제출(RFC 2476)과 SMTP-AUTH(RFC 2554)는 1998년과 1999년에 도입되었으며, 모두 이메일 전달의 새로운 동향을 보여준다. 원래 SMTP 서버는 일반적으로 조직 내부에 있었고, 외부에서 조직으로 메일을 받고 조직에서 외부로 메시지를 전달했다. 그러나 시간이 지남에 따라 SMTP 서버(메일 전송 에이전트)는 실제로 메시지 제출 에이전트 역할을 확장하여 일부는 이제 조직의 외부에서 메일을 전달했다(예: 회사 임원이 출장 중에 회사 SMTP 서버를 사용하여 이메일을 보내려는 경우). 월드 와이드 웹의 급속한 확장과 인기에 따른 결과인 이 문제는 SMTP가 원치 않는 이메일(스팸) 중계와 같은 남용을 방지하기 위해 특정 규칙과 메일 중계 및 사용자 인증 방법을 포함해야 함을 의미했다. 메시지 제출(RFC 2476)에 대한 작업은 원래 인기 있는 메일 서버가 종종 문제를 해결하기 위해 메일을 다시 작성(예: 정규화되지 않은 주소에 도메인 이름 추가)하려고 했기 때문에 시작되었다. 이러한 동작은 수정되는 메시지가 초기 제출인 경우 유용하지만, 메시지가 다른 곳에서 시작되어 중계되는 경우 위험하고 해롭다. 메일을 제출과 중계로 명확하게 분리하는 것이 제출 다시 쓰기를 허용하고 장려하면서 중계 다시 쓰기를 금지하는 방법으로 간주되었다. 스팸이 더욱 만연해짐에 따라 조직에서 발송되는 메일의 권한 부여와 추적성을 제공하는 방법으로도 간주되었다. 중계와 제출의 이러한 분리는 빠르게 현대 이메일 보안 관행의 기반이 되었다.

이 프로토콜은 순수하게 ASCII 텍스트 기반으로 시작되었기 때문에 이진 파일이나 많은 비영어권 언어의 문자를 잘 처리하지 못했다. SMTP를 통해 이진 파일을 인코딩하기 위해 다목적 인터넷 메일 확장(MIME)과 같은 표준이 개발되었다. Sendmail 이후에 개발된 메일 전송 에이전트(MTA)는 또한 임의의 텍스트 데이터(8비트 ASCII 유사 문자 인코딩)를 SMTP를 통해 전송할 수 있는 대체 "8비트만 전송" 전략을 사용할 수 있도록 8비트 클린으로 구현되는 경향이 있었다. 이메일 주소 자체는 여전히 ASCII만 허용했지만, 공급업체 간의 문자 집합 매핑 차이로 인해 모지바케는 여전히 문제였다. 오늘날 8비트 클린 MTA는 8BITMIME 확장을 지원하여 일부 이진 파일을 일반 텍스트처럼 거의 쉽게 전송할 수 있도록 하는 경향이 있다(줄 길이 및 허용되는 옥텟 값에 대한 제한은 여전히 적용되므로 대부분의 비텍스트 데이터 및 일부 텍스트 형식에는 MIME 인코딩이 필요합니다). 2012년에는 UTF-8 텍스트를 지원하는 `SMTPUTF8` 확장이 만들어져 라틴 문자가 아닌 스크립트(예: 키릴 또는 한자)로 된 국제 콘텐츠 및 주소를 허용했다.

존 포스텔, 에릭 올먼, 데이브 크로커, 네드 프리드, 랜달 겔렌스, 존 클렌신, 키스 무어 등 많은 사람들이 핵심 SMTP 사양에 기여했다.

3. 프로토콜 개요

SMTP^영어는 연결 지향적인 텍스트 기반 프로토콜이다. 메일을 보내는 사람(클라이언트)은 명령 문자열을 전송하고, TCP 연결과 같이 신뢰할 수 있는 데이터 스트림 채널을 통해 필요한 데이터를 제공하여 메일 수신자(서버)와 통신한다.^[24]

이메일은 메일 클라이언트(MUA)가 SMTP를 통해 메일 서버(MSA)에 제출한다. 이때 주로 TCP 587번 포트를 사용하지만, 대부분의 메일 박스 제공업체는 여전히 기존 25번 포트를 통한 제출도 허용한다. MSA는 메일을 MTA에 전달하는데, 종종 이 두 에이전트는 동일한 머신에서 서로 다른 옵션으로 실행되는 동일한 소프트웨어의 인스턴스이다.

경계 MTA는 DNS를 사용하여 수신자 도메인(@ 기호 오른쪽 이메일 주소 부분)에 대한 메일 교환기(MX) 레코드를 조회한다. MX 레코드에는 대상 MTA의 이름이 포함되어 있으며, 보내는 MTA는 이를 기반으로 수신자 서버를 선택하고 연결하여 메일 교환을 완료한다.

메시지 전달은 두 MTA 간의 단일 연결 또는 중개 시스템을 통한 일련의 홉(hop)으로 발생할 수 있다. 수신 SMTP 서버는 최종 목적지, 중간 "릴레이"(메시지를 저장하고 전달) 또는 "게이트웨이"(SMTP 이외의 프로토콜을 사용하여 메시지 전달)일 수 있다. 2.1절에 따라 각 홉은 메시지에 대한 책임의 공식적인 인계이며, 수신 서버는 메시지를 전달하거나 전달 실패를 적절하게 보고해야 한다.

최종 홉이 들어오는 메시지를 수락하면 MDA에 전달하여 로컬 사서함 형식으로 메시지를 저장한다. 이 수신 작업은 하나 또는 여러 대의 컴퓨터를 사용하여 수행될 수 있다. MDA는 메시지를 저장소에 직접 전달하거나, SMTP 또는 LMTP과 같은 프로토콜을 사용하여 네트워크를 통해 전달할 수 있다.

로컬 메일 서버에 전달된 메일은 인증된 메일 클라이언트(MUA)가 IMAP 또는 POP을 사용하여 검색할 수 있도록 저장된다. 웹메일 클라이언트는 두 가지 방법을 모두 사용할 수 있지만, 검색 프로토콜은 공식 표준이 아닌 경우가 많다.

SMTP는 메시지 ''전송''을 정의하며, 봉투 발신자와 같은 메일 ''봉투''와 해당 매개변수를 정의한다. 그러나 헤더(''추적 정보'' 제외)나 메시지 자체의 본문은 정의하지 않는다. SMTP(봉투)는 STD 10 및 에서, 메시지(헤더 및 본문)는 STD 11 및 에서 인터넷 메시지 형식으로 정의된다.

3. 1. SMTP 통신 과정

SMTP 세션은 클라이언트가 명령을 보내고 서버가 응답하는 방식으로 이루어진다. 주요 명령어와 서버 응답 코드는 다음과 같다.^[24]

MAIL 명령: 반환 주소(return-path, bounce 주소 등으로 불림)를 설정한다.
RCPT 명령: 메시지 수신자를 설정한다. 수신자가 여러 명일 경우 이 명령을 여러 번 사용할 수 있다.
DATA 명령: 메시지 텍스트의 시작을 알린다. 메시지 내용은 헤더와 본문으로 구성되며, 빈 줄로 구분된다.

서버의 응답 코드는 다음과 같이 분류된다.

2xx: 긍정적인 응답 (성공)
4xx: 일시적인 오류
5xx: 영구적인 오류

SMTP 클라이언트(발신자)는 메일 사용자 에이전트(MUA, 이메일 클라이언트) 또는 메일 전송 에이전트(MTA, 중계 서버)일 수 있다. MTA는 메시지 큐를 유지하여 일시적인 오류 발생 시 메시지 전송을 다시 시도한다.

다음은 SMTP 통신의 예시이다.

S: 220 smtp.example.com ESMTP Postfix

C: HELO relay.example.org

S: 250 Hello relay.example.org, I am glad to meet you

C: MAIL FROM:

S: 250 Ok

C: RCPT TO:

S: 250 Ok

C: RCPT TO:

S: 250 Ok

C: DATA

S: 354 End data with .

C: Hello Alice.

C: This is a test message with 5 header fields and 4 lines in the message body.

C: Your friend,

C: Bob

C: .

S: 250 Ok: queued as 12345

C: QUIT

S: 221 Bye

{The server closes the connection}

클라이언트는 `MAIL FROM` 명령으로 메시지의 원본 이메일 주소를 알리고, `RCPT TO` 명령으로 수신자를 지정한다. `DATA` 명령 이후 메시지 본문을 전송하고, 데이터 끝 시퀀스(`.`)로 종료한다.

메시지 본문에 마침표만 있는 줄이 있을 수 있으므로, 클라이언트는 줄 시작이 마침표일 때 마침표를 추가하는 ''닷 스터핑''을 수행한다. 서버는 이를 제거한다.

서버가 긍정 응답(250 Ok)을 하면 메시지 전달 책임을 맡았음을 의미한다. 통신 오류 시 메시지가 중복될 수 있다. `QUIT` 명령은 세션을 종료한다.

SMTP는 TCP를 주로 사용하며, '''메시지 전송'''을 정의한다. 메시지 내용은 별도로 정의된다.

3. 2. SMTP 통신의 예

메일을 보내는 송신자(클라이언트)와 메일을 받는 수신자(서버) 간의 연결이 성립된 후 이루어지는 SMTP 세션은 다음과 같다. 아래 대화 과정에서 클라이언트가 보내는 메시지는 "C:", 서버가 보내는 메시지는 "S:"를 맨 앞에 표시한다.

텔넷 명령어를 사용하여 연결을 만들 수 있다.

`telnet www.example.com 25`

이 명령으로 클라이언트에서 호스트인 www.example.com으로 SMTP 연결을 시작할 수 있다.

```

S: 220 smtp.example.com ESMTP Postfix

C: HELO relay.example.com

S: 250 smtp.example.com, I am glad to meet you

C: MAIL FROM:

S: 250 Ok

C: RCPT TO:

S: 250 Ok

C: RCPT TO:

S: 250 Ok

C: DATA

S: 354 End data with .

C: From: "Bob Example"

C: To: Alice Example

C: Cc: theboss@example.com>

C: Date: Tue, 15 January 2008 16:02:43 -0500

C: Subject: Test message

C:

C: Hello Alice.

C: This is a test message with 5 header fields and 4 lines in the message body.

C: Your friend,

C: Bob

C: .

S: 250 Ok: queued as 12345

C: QUIT

S: 221 Bye

{The server closes the connection}

```

위 예시는 클라이언트가 `HELO` 명령으로 자신을 소개하고, `MAIL FROM`, `RCPT TO` 명령으로 메일 발신자와 수신자를 지정한 후, `DATA` 명령으로 메일 본문을 전송하는 과정을 보여준다. 메일 본문은 `From`, `To`, `Cc`, `Date`, `Subject` 등의 헤더 필드와 실제 메시지 내용으로 구성된다. 메시지 본문이 끝났음을 알리기 위해 `.`를 사용한다. 마지막으로 `QUIT` 명령으로 세션을 종료한다.

3. 3. SMTP 인증

원래 SMTP에는 사용자 인증 절차가 없었지만, 인터넷 보급과 함께 그 필요성이 요구되어, SASL 메커니즘을 이용한 인증 기능이 SMTP-AUTH (SMTP Authentication) (4954)로 표준화되었다. 인증 방식으로는 PLAIN, LOGIN, DIGEST-MD5, CRAM-MD5 등이 널리 이용되고 있다.

SMTP-AUTH 표준화 이전에는 POP before SMTP로 불리는, SMTP 외부 기구를 이용한 사용자 제한 방법이 고안되어 현재까지 사용되고 있다.

4. SMTP 확장

1995년 11월, 에서 정의된 확장된 간편 메일 전송 프로토콜(ESMTP)은 원래 SMTP에 부족했던 기능을 추가하기 위한 기존 및 향후 확장에 대한 일반적인 구조를 확립했다. ESMTP는 ESMTP 클라이언트와 서버를 식별하고 서버가 지원하는 확장 기능을 나타낼 수 있는 일관되고 관리 가능한 방법을 정의한다.

1998년과 1999년에 메시지 제출()과 SMTP-AUTH()가 도입되면서 이메일 전달에 새로운 동향이 나타났다. 원래 SMTP 서버는 주로 조직 내부에 위치하여 외부에서 조직으로 메일을 받고 조직에서 외부로 메시지를 전달했다. 그러나 시간이 지나면서 SMTP 서버(MTA)는 메시지 제출 에이전트의 역할을 확장하여, 일부는 이제 조직 외부에서 메일을 전달하게 되었다. (예: 회사 임원이 출장 중에 회사 SMTP 서버를 사용하여 이메일을 보내는 경우) 월드 와이드 웹의 급속한 확장과 인기로 인해, SMTP는 원치 않는 이메일(스팸) 중계와 같은 남용을 방지하기 위해 특정 규칙과 메일 중계 및 사용자 인증 방법을 포함해야 했다.

메시지 제출() 작업은 인기 있는 메일 서버가 문제를 해결하기 위해 메일을 다시 작성(예: 정규화되지 않은 주소에 도메인 이름 추가)하려는 시도에서 시작되었다. 이러한 동작은 수정되는 메시지가 초기 제출인 경우에는 유용하지만, 메시지가 다른 곳에서 시작되어 중계되는 경우에는 위험하고 해로웠다. 메일 제출과 중계를 명확하게 분리하는 것은 제출 다시 쓰기를 허용하고 장려하면서 중계 다시 쓰기를 금지하는 방법으로 간주되었다. 스팸이 만연해짐에 따라 조직에서 발송되는 메일의 권한 부여와 추적성을 제공하는 방법으로도 여겨졌다. 중계와 제출의 분리는 현대 이메일 보안 관행의 기반이 되었다.

초기 프로토콜은 순수하게 ASCII 텍스트 기반이었기 때문에 이진 파일이나 비영어권 언어의 문자를 처리하는 데 어려움이 있었다. SMTP를 통해 이진 파일을 인코딩하기 위해 MIME과 같은 표준이 개발되었다. Sendmail 이후 개발된 MTA는 임의의 텍스트 데이터(8비트 ASCII 유사 문자 인코딩)를 SMTP를 통해 전송할 수 있는 "8비트만 전송" 전략을 사용하도록 8비트 클린으로 구현되는 경향이 있었다. 이메일 주소 자체는 여전히 ASCII만 허용했지만, 공급업체 간 문자 집합 매핑 차이로 인해 모지바케는 여전히 문제였다. 오늘날 8비트 클린 MTA는 8BITMIME 확장을 지원하여 일부 이진 파일을 일반 텍스트처럼 쉽게 전송할 수 있도록 한다. (줄 길이 및 허용되는 옥텟 값에 대한 제한은 여전히 적용되므로 대부분의 비텍스트 데이터 및 일부 텍스트 형식에는 MIME 인코딩이 필요) 2012년에는 UTF-8 텍스트를 지원하는 `SMTPUTF8` 확장이 만들어져 라틴 문자가 아닌 스크립트(예: 키릴 또는 한자)로 된 국제 콘텐츠 및 주소를 허용했다.

SMTP와 마찬가지로 ESMTP는 인터넷 메일을 전송하는 데 사용되는 프로토콜이다. 서버 간 전송 프로토콜과 (제한된 동작이 적용된) 메일 제출 프로토콜 모두로 사용된다.

ESMT 클라이언트의 주요 식별 기능은 원래의 표준인 `HELO` (Hello)가 아닌 `EHLO` (Extended HELLO) 명령어로 전송을 시작하는 것이다. 서버는 구성에 따라 성공(코드 250), 실패(코드 550) 또는 오류(코드 500, 501, 502, 504 또는 421)로 응답한다. ESMTP 서버는 지원되는 확장 기능 목록과 해당 도메인을 포함하는 여러 줄 응답으로 코드 250 OK를 반환한다. RFC 821 준수 서버는 오류 코드 500을 반환하여 ESMTP 클라이언트가 `HELO` 또는 `QUIT`을 시도하도록 한다.

각 서비스 확장은 이후 RFC에서 승인된 형식으로 정의되고 인터넷 번호 할당 기관(IANA)에 등록된다. 최초 정의는 RFC 821 선택적 서비스였다. `SEND`, `SOML` (Send or Mail), `SAML` (Send and Mail), `EXPN`, `HELP` 및 `TURN`이다. 추가 SMTP 동사의 형식이 설정되었고 `MAIL` 및 `RCPT`에 새로운 매개변수가 추가되었다.

오늘날 사용되는 몇 가지 일반적인 키워드는 다음과 같다. (모두 명령어에 해당하는 것은 아니다)

`8BITMIME` – 8비트 데이터 전송,
`ATRN` – 인증된 `TURN` (주문형 메일 중계용),
`AUTH` – 인증된 SMTP,
`CHUNKING` – 청킹,
`DSN` – 배달 상태 알림, (가변 봉투 반환 경로 참조)
`ETRN` – 원격 메시지 큐 시작 명령 `TURN`의 확장 버전,
`HELP` – 유용한 정보 제공,
`PIPELINING` – 명령 파이프라이닝,
`SIZE` – 메시지 크기 선언,
`STARTTLS` – 전송 계층 보안, (2002)
`SMTPUTF8` – 사서함 이름과 헤더 필드에서 UTF-8 인코딩 허용,
`UTF8SMTP` – 사서함 이름과 헤더 필드에서 UTF-8 인코딩 허용, (사용되지 않음^[34])

ESMT 형식은 (RFC 821 대체)에서 다시 명시되었고 2008년 에서 최신 정의로 업데이트되었다. 서버에서 `EHLO` 명령어에 대한 지원이 필수가 되었고 `HELO`는 필수 대체 명령어로 지정되었다.

비표준, 미등록 서비스 확장은 양자 간 합의에 의해 사용될 수 있으며, 이러한 서비스는 "X"로 시작하는 `EHLO` 메시지 키워드와 마찬가지로 표시된 추가 매개변수 또는 동사로 표시된다.

SMTP 명령어는 대소문자를 구분하지 않는다. 강조를 위해 대문자로 표시되어 있지만, 특정 대소문자 변환 방법을 요구하는 SMTP 서버는 표준 위반이다.

4. 1. 확장 기능 발견 메커니즘

클라이언트는 `HELO` 명령 대신 `EHLO` 인사말을 사용하여 서버가 지원하는 옵션을 확인할 수 있다.^[30] 서버가 `EHLO` 인사말을 지원하지 않는 경우 클라이언트는 `HELO` 명령을 대신 사용할 수 있다.^[30]

예를 들어, `smtp2.example.com` 서버는 다음과 같이 응답할 수 있다.

```

250-smtp2.example.com Hello bob.example.org [192.0.2.201]

250-SIZE 14680064

250-PIPELINING

250 HELP

```

위 응답에서 `smtp2.example.com`은 최대 146,800,640억를 초과하지 않는 고정된 최대 메시지 크기를 허용한다고 선언한다.

`EHLO` 응답의 `SIZE` 확장에 대한 숫자 매개변수는 선택 사항이다. 클라이언트는 `MAIL FROM` 명령을 실행할 때 전송 중인 메시지 크기에 대한 숫자 추정치를 포함할 수 있으며, 이를 통해 서버는 너무 큰 메시지의 수신을 거부할 수 있다.

4. 2. 이진 데이터 전송

SMTP는 원래 ASCII 텍스트 본문 하나만 지원했기 때문에, 모든 이진 데이터는 전송 전에 메시지 본문에 텍스트로 인코딩된 후 수신자에 의해 디코딩되어야 했다. 이진-텍스트 인코딩 방식, 예를 들어 uuencode와 BinHex가 일반적으로 사용되었다.

이러한 문제를 해결하기 위해 다음과 같은 SMTP 확장 기능이 개발되었다.

8BITMIME: 1994년에 IETF 1652로 표준화되었으며,^[32] 7비트 ASCII 문자 집합 외부의 옥텟을 포함하는 전자 우편 메시지의 투명한 교환을 용이하게 한다. 이는 일반적으로 Base64로 인코딩된 MIME 콘텐츠 부분으로 인코딩하여 가능하다. 행은 <CRLF>로 1000옥텟을 넘지 않도록 구분되며, 점(.)만 있는 행으로 DATA의 끝을 나타내는 점은 변하지 않으므로, 바이너리 전송을 가능하게 하는 것이 아니라 8비트 문자 코드를 의도한 것이다.

CHUNKING: DATA 명령어 대신 BDAT 명령어를 사용한다. 인수로는 바이트 크기를 지정하며, 그 후에 전송된 데이터를 그 길이만큼 받는다. 따라서 마침표(.)만으로 구성된 줄로 끝을 나타낼 필요가 없다. 또한, 여러 번의 BDAT 명령어로 나누는 것도 가능하다. 그 경우를 위해 BDAT 명령어의 두 번째 인수에 "LAST"를 지정하면 데이터 전송이 종료되었음을 나타낸다.

BINARYMIME: 바이너리 전송을 가능하게 하는 확장이다. CHUNK 확장과 함께 사용할 때에만 사용할 수 있다.

4. 3. 메일 전송 메커니즘 확장

'''주문형 메일 중계'''(영어: On-Demand Mail Relay, ODMR)는 간헐적으로 연결되는 SMTP 서버가 연결될 때 대기 중인 이메일을 수신할 수 있도록 하는 RFC 2645에 표준화된 SMTP 확장 기능이다.^[26]

4. 4. 국제화 확장

원래 SMTP는 ASCII 문자만으로 구성된 이메일 주소만 지원하여, 라틴 문자가 아닌 고유 문자를 사용하거나 ASCII 문자 집합에 없는 발음 부호 (diacritic)를 사용하는 사용자에게 불편을 초래했다. 이러한 제한은 주소 이름에 UTF-8을 사용할 수 있도록 하는 확장 기능을 통해 완화되었다. 은 실험적인^[31] UTF8SMTP 명령어를 도입했고, 나중에 이 SMTPUTF8 명령어를 도입하면서 대체되었다. 이러한 확장 기능은 발음 부호가 있는 이메일 주소나 그리스어 및 중국어와 같은 다른 언어 문자처럼, 여러 바이트 및 ASCII가 아닌 문자를 지원한다.^[33]

현재 지원은 제한적이지만, 라틴 문자(ASCII)가 외국 문자인 중국과 같은 많은 사용자 기반을 가진 국가에서 및 관련 RFC의 광범위한 채택에 대한 강한 관심이 있다.

SMTPUTF8을 지원하는 서버는 다음과 같다.

서버 소프트웨어	지원 버전
Postfix	3.0 이상^[40]
Momentum	4.1^[41] 및 3.6.5 이상
sendmail	8.17.1에서 실험적 지원
exim	4.86부터 실험적, 4.96에서 상당히 성숙
CommuniGate Pro	6.2.2 이상^[42]
Courier-MTA	1.0 이상^[43]
Halon	4.0 이상^[44]
Microsoft Exchange Server	프로토콜 개정판 14.0부터^[45]
Haraka	해당사항 있음^[46]
오라클 커뮤니케이션 메시징 서버	8.0.2 이상^[47]

4. 5. 기타 확장

SIZE (RFC 1870)^[31]: 서버가 수락 가능한 최대 메시지 크기를 미리 확인할 수 있는 기능이다. ESMTP 서버는 `EHLO` 명령에 대한 응답으로 최대 `SIZE`를 선언한다. 클라이언트는 `MAIL FROM` 명령에 메시지 크기 추정치를 포함시켜 서버가 너무 큰 메시지 수신을 거부할 수 있도록 할 수 있다. 이를 통해 네트워크 리소스를 낭비하는 것을 방지할 수 있다.
PIPELINING (RFC 2920)^[30]: 여러 개의 명령을 연속해서 보내는 기능이다. 목적지가 여러 곳일 때 매번 응답을 기다리지 않고 다음 명령을 보낼 수 있어 시간을 절약할 수 있다.
DSN (Delivery Status Notification, RFC 3461)^[34]: 배달 상태 알림 기능을 제공한다. (가변 봉투 반환 경로 참조)
STARTTLS (RFC 3207)^[34]: 전송 계층 보안(TLS)을 사용하여 암호화된 통신을 지원한다.

5. 보안

SMTP는 초기 설계상 발신자 인증 기능이 없어 이메일 스푸핑이 가능했고, 이는 이메일 스팸과 피싱에 악용될 수 있었다.^[53]^[54] 이러한 보안 취약점은 SMTP를 수정하거나 대체하려는 시도로 이어졌지만, SMTP의 광범위한 설치 기반으로 인해 큰 진전을 이루지 못했다.

SMTP는 인터넷 기술 특수 태스크 포스(Internet Engineering Task Force, IETF)에서 표준화된 이메일 전송 프로토콜이다. 1980년 9월 IETF RFC 772에서 메일 전송 프로토콜(Mail Transfer Protocol)이라는 명칭으로 제안되었고, 두 차례 개정을 거쳐 1982년 8월 IETF RFC 821/STD0010^[56]으로 간이 메일 전송 프로토콜(SMTP) 표준이 되었다.

이후 SMTP는 인터넷 보급에 따른 다양한 이메일 확장 기능 구현 및 정리 필요에 의해 2001년 4월 IETF RFC 2821^[57]로 제안 표준(Proposed Standard)이 되었다. 2008년 10월에는 서버 외부 공격, IPv6 주소, 발신자 정책 프레임워크(SPF, IETF RFC 4408), 도메인키 식별 메일(DKIM, IETF RFC 4871) 등에 대응하기 위해 IETF RFC 5321^[57]로 다시 개정되었다.

SMTP는 원래 텍스트 기반 프로토콜이며, 모든 요청/응답 메시지와 메일 데이터가 7비트 ASCII여야 한다는 제한이 있었다. 그러나 영어 이외의 언어나 바이너리 파일을 처리해야 할 필요성이 있었고, 이에 따라 이메일에 멀티퍼포즈 인터넷 메일 확장(Multipurpose Internet Mail Extensions, MIME)이라는 표준이 추가되었으며, SMTP 자체에도 8비트 전송 확장이 표준화되었다.

5. 1. 스푸핑 및 스팸 대응

원래 SMTP 설계에는 발신자를 인증하거나 서버가 발신자를 대신하여 이메일을 보낼 권한이 있는지 확인하는 기능이 없었기 때문에 이메일 스푸핑이 가능했고, 이메일 스팸과 피싱에 흔히 사용되었다.^[53]^[54]

메일 서버는 와 같은 표준을 엄격하게 시행하고, 도메인키 식별 메일, 발신자 정책 프레임워크, DMARC, DNSBL, 그레이리스트와 같은 다양한 기법을 사용하여 의심스러운 이메일을 거부하거나 격리한다.^[55]

5. 2. 보안 확장

메일 전달은 일반 텍스트와 암호화된 연결 모두를 통해 발생할 수 있지만, 통신 당사자는 상대방의 보안 채널 사용 가능성을 미리 알지 못할 수 있다.

STARTTLS 확장 기능을 통해 지원하는 SMTP 서버는 연결된 클라이언트에 TLS 암호화 통신을 지원하며 STARTTLS 명령어를 보내 연결을 업그레이드할 수 있는 기회를 제공함을 알릴 수 있다.^[48] 확장 기능을 지원하는 서버가 자체적으로 구현한다고 해서 본질적으로 보안상의 이점을 얻는 것은 아니다.^[48] TLS 암호화 세션으로 업그레이드 여부는 연결된 클라이언트가 이 옵션을 사용하기로 결정하는지 여부에 따라 달라지므로, ''기회적'' TLS라는 용어가 사용된다.

STARTTLS는 STARTTLS 협상이 일반 텍스트로 이루어지고 적극적인 공격자가 STARTTLS 명령어를 간단하게 제거할 수 있기 때문에 수동 관찰 공격에 대해서만 효과적이다.^[48] 이러한 유형의 중간자 공격은 때때로 STRIPTLS로 불리며, 한쪽에서 보낸 암호화 협상 정보가 다른 쪽에 도달하지 못하는 경우이다. 이 시나리오에서 양쪽 모두 잘못되거나 예상치 못한 응답을 상대방이 STARTTLS를 제대로 지원하지 않는다는 표시로 받아들이고 기존의 일반 텍스트 메일 전송으로 기본 설정된다.^[48] 다른 RFC에서 IMAP 및 POP3에 대해서도 STARTTLS가 정의되어 있지만, 이러한 프로토콜은 서로 다른 목적을 제공한다. SMTP는 메시지 전달 에이전트 간의 통신에 사용되는 반면, IMAP과 POP3는 최종 클라이언트와 메시지 전달 에이전트를 위해 사용된다.

2014년 전자 프런티어 재단은 "HTTPS Everywhere" 목록과 유사하게, 사전 통신 없이 안전한 통신을 지원하는 다른 당사자를 찾을 수 있도록 하는 "STARTTLS Everywhere" 프로젝트를 시작했다. 이 프로젝트는 2021년 4월 29일에 제출물 접수를 중단했으며, EFF는 피어의 TLS 지원에 대한 정보를 확인하기 위해 DANE 및 MTA-STS로 전환할 것을 권장했다.^[49]

는 공식적으로 일반 텍스트를 사용하지 않는 것을 선언하고 메일 제출 및 액세스에 항상 TLS를 사용하고 암시적 TLS가 포함된 포트를 추가할 것을 권장한다. 는 DNS 레코드가 메일 서버의 암호화 기능을 선언할 수 있는 기능을 도입했다. DNSSEC을 활용하여 메일 서버 운영자는 TLS 인증서의 해시를 게시할 수 있으므로 암호화되지 않은 통신의 가능성을 줄일 수 있다.^[50]

마이크로소프트(Microsoft)는 2024년 말까지 Exchange Online 고객을 위해 SMTP DANE를 완벽하게 지원할 계획이다.^[51] 2018년에 발표된 "SMTP MTA Strict Transport Security (MTA-STS)"는 메일 서버가 서버의 특정 파일과 특정 DNS TXT 레코드에서 보안 채널을 사용할 수 있는 능력을 선언하는 프로토콜을 정의함으로써 적극적인 공격자의 문제를 해결하고자 한다.^[48] 의존 당사자는 해당 레코드의 존재 여부를 정기적으로 확인하고, 레코드에 지정된 시간 동안 캐싱하며, 레코드가 만료될 때까지 안전하지 않은 채널을 통해 통신하지 않는다.^[48] MTA-STS 레코드는 메일 서버 간의 SMTP 트래픽에만 적용되며, 사용자 클라이언트와 메일 서버 간의 통신은 SMTP/MSA, IMAP, POP3 또는 HTTPS와 함께 조직적 또는 기술적 정책을 통해 전송 계층 보안으로 보호된다는 점에 유의해야 한다. 기본적으로 MTA-STS는 이러한 정책을 제3자에게 확장하는 수단이다.

2019년 4월 구글 메일은 MTA-STS 지원을 발표했다.^[52] 메시지를 안전하게 전달하도록 설계된 프로토콜은 잘못된 구성이나 의도적인 적극적인 간섭으로 인해 메시지가 전달되지 않거나 암호화되지 않거나 인증되지 않은 채널을 통해 전달될 수 있다. "SMTP TLS 보고"는 수신 도메인과 잠재적인 실패에 대한 특정 정보를 공유하기 위한 보고 메커니즘 및 형식을 설명한다. 그러면 수신 도메인은 이 정보를 사용하여 잠재적인 공격을 감지하고 의도하지 않은 잘못된 구성을 진단할 수 있다.

2019년 4월 Google Mail은 SMTP TLS 보고 기능을 지원한다고 발표했다.^[52] SMTP 암호화는 FTP 등 다른 텍스트 기반 프로토콜과 마찬가지로, 중간부터 암호화를 시작하는 STARTTLS와 처음부터 암호화하는 SMTPS의 두 가지가 있다. SMTPS의 경우 포트 번호를 동일하게 할 수 없으므로 465를 사용한다.

6. 아웃바운드 메일 SMTP 서버

이메일 클라이언트는 초기 SMTP 서버의 IP 주소를 알아야 하며, 이는 일반적으로 도메인 이름 시스템(DNS) 이름으로 주어지는 구성 요소로 제공된다. 이 서버는 사용자를 대신하여 발신 메시지를 전달한다.

6. 1. 접근 제한

과거에는 많은 시스템이 클라이언트의 위치(IP 주소)에 따라 사용 제한을 적용하여, 서버 관리자가 제어하는 IP 주소를 가진 클라이언트만 사용하도록 허용했다. 다른 클라이언트 IP 주소의 사용은 허용되지 않았다.^[1]

최신 SMTP 서버는 일반적으로 접근을 허용하기 전에 자격 증명을 통한 클라이언트 인증을 요구하는 대안 시스템을 제공한다.^[1]

이 시스템에서는 인터넷 서비스 제공업체(ISP)의 SMTP 서버가 ISP 네트워크 외부 사용자의 접근을 허용하지 않는다. 더 정확히 말하면, 서버는 ISP가 제공하는 IP 주소를 가진 사용자에게만 접근을 허용할 수 있으며, 이는 해당 ISP를 사용하여 인터넷에 연결되어야 함을 의미한다. 휴대폰 사용자는 종종 일반 ISP의 네트워크가 아닌 다른 네트워크에 있을 수 있으며, 그럴 경우 구성된 SMTP 서버가 더 이상 접근할 수 없으므로 이메일 전송이 실패하는 것을 알게 된다.^[1]

이 시스템에는 여러 가지 변형이 있다. 예를 들어, 어떤 기관의 SMTP 서버는 동일한 네트워크의 사용자에게만 서비스를 제공하여 방화벽을 통해 광범위한 인터넷의 사용자 접근을 차단할 수 있다. 또는 서버는 클라이언트의 IP 주소에 대한 범위 검사를 수행할 수 있다. 이러한 방법은 일반적으로 기업이나 대학교와 같은 기관에서 내부적으로만 사용할 수 있도록 아웃바운드 메일용 SMTP 서버를 제공하는 데 사용되었다. 그러나 이러한 대부분의 기관은 이제 클라이언트 인증 방법을 사용한다.^[1]

사용자가 휴대용 기기를 사용하고 인터넷에 연결하기 위해 다른 ISP를 사용할 수 있는 경우 이러한 사용 제한은 번거롭고, 구성된 아웃바운드 이메일 SMTP 서버 주소를 변경하는 것은 비현실적이다. 변경할 필요가 없는 이메일 클라이언트 구성 정보를 사용할 수 있는 것이 매우 바람직하다.^[1]

6. 2. 포트

메일 서버 간 통신은 일반적으로 SMTP에 지정된 표준 TCP 포트 25를 사용한다.^[27]

그러나 메일 ''클라이언트''는 포트 25를 사용하지 않고 대신 특정 "제출" 포트를 사용한다. 메일 서비스는 일반적으로 다음 포트 중 하나에서 클라이언트의 이메일 제출을 허용한다.

587 (제출): RFC 6409에 정의됨
465: 이 포트는 RFC 2487 이후 사용되지 않았으나, RFC 8314의 문제점으로 인해 다시 사용되고 있다.

포트 2525 및 기타 포트는 일부 개별 제공업체에서 사용할 수 있지만 공식적으로 지원된 적은 없다.

SMTP 암호화는 STARTTLS와 SMTPS의 두 가지가 있다. STARTTLS는 중간부터 암호화를 시작하고, SMTPS는 처음부터 암호화한다. SMTPS는 포트 번호를 동일하게 할 수 없어 포트 465를 사용한다.

많은 인터넷 서비스 제공업체는 스팸 방지 조치^[27]와 열린 포트 유지 비용 문제로 인해 고객의 모든 발신 포트 25 트래픽을 차단한다. 포트 25를 개방해야 하는 소수의 고객에게는 더 많은 요금을 부과할 수 있다.

7. 관련 RFC

RFC 번호	제목	비고
RFC 1123	인터넷 호스트 요구 사항—애플리케이션 및 지원 (STD 3)	RFC 5321에 의해 업데이트됨
RFC 1870	SMTP 서비스 확장 - 메시지 크기 선언	RFC 1653 폐지
RFC 2505	SMTP MTA에 대한 스팸 방지 권장 사항 (BCP 30)
RFC 2920	SMTP 서비스 확장 - 명령 파이프라이닝 (STD 60)
RFC 3030	대용량 및 바이너리 MIME 메시지 전송을 위한 SMTP 서비스 확장
RFC 3207	전송 계층 보안을 통한 보안 SMTP를 위한 SMTP 서비스 확장	RFC 2487 폐지
RFC 3461	배달 상태 알림을 위한 SMTP 서비스 확장	RFC 1891 폐지, RFC 3798에 의해 업데이트됨
RFC 3463	SMTP를 위한 향상된 상태 코드	RFC 1893 폐지, RFC 5248에 의해 업데이트됨
RFC 3464	배달 상태 알림을 위한 확장 가능한 메시지 형식	RFC 1894 폐지
RFC 3798	메시지 배달 알림	RFC 3461 업데이트
RFC 3834	전자 우편에 대한 자동 응답 권장 사항
RFC 4952	국제화된 이메일 개요 및 프레임워크	RFC 5336에 의해 업데이트됨
RFC 4954	인증을 위한 SMTP 서비스 확장	RFC 2554 폐지, RFC 3463, RFC 5248에 의해 업데이트됨
RFC 5068	이메일 제출 작업: 액세스 및 책임 요구 사항 (BCP 134)
RFC 5248	SMTP 향상된 메일 시스템 상태 코드 레지스트리 (BCP 138)	RFC 3463 업데이트
RFC 5321	간이 메일 전송 프로토콜	RFC 821, RFC 974, RFC 1869, RFC 2821 폐지, RFC 1123 업데이트
RFC 5322	인터넷 메시지 형식	RFC 822, RFC 2822 폐지
RFC 5504	이메일 주소 국제화를 위한 다운그레이딩 메커니즘
RFC 6409	메일 제출을 위한 메시지 (STD 72)	RFC 4409, RFC 2476 폐지
RFC 6522	메일 시스템 관리 메시지 보고를 위한 Multipart/Report 콘텐츠 유형	RFC 3462, RFC 1892 폐지
RFC 6531	국제화된 이메일 주소를 위한 SMTP 확장	RFC 2821, RFC 2822, RFC 4952, RFC 5336 업데이트
RFC 7504	SMTP 521 및 556 응답 코드
RFC 8314	평문은 더 이상 사용되지 않음: 이메일 제출 및 액세스를 위한 전송 계층 보안(TLS) 사용

참조

_[1] 웹아카이브 The History of Electronic Mail http://www.multician[...] 2017-12-02
_[2] 웹사이트 The First Network Email //openmap.bbn.com/~t[...] BBN
_[3] 이미지 The First Email Computer //kingsmtp.com/the-f[...]
_[4] 웹아카이브 Dan Murphy's TENEX and TOPS-20 Papers http://www.opost.com[...] 2007-11-18
_[5] IETF RFC A Proposed Mail Protocol
_[6] 논문 Framework and Functions of the "MS" Personal Message System https://www.rand.org[...] 2022-04-17
_[7] IETF RFC Network Mail Meeting Summary
_[8] RFC Standard for the Format of ARPA Network Text Message 1977-11-21
_[9] 뉴스 A history of e-mail: Collaboration, innovation and the birth of a system https://www.washingt[...] Washington Post 2024-07-07
_[10] 논문 INWG and the Conception of the Internet: An Eyewitness Account 2011-00-00
_[11] 논문 A Basic Mail Scheme for EIN INWG 192 1979-02-00
_[12] IETF IEN
_[13] IETF IEN
_[14] 웹사이트 Internet Experiment Note Index https://www.rfc-edit[...] 2024-07-07
_[15] 보고서 Simple Mail Transfer Protocol https://doi.org/10.1[...] RFC Editor 1982-08-00
_[16] 웹아카이브 Tldp.org http://tldp.org/HOWT[...] 2007-08-25
_[17] 웹아카이브 draft-barber-uucp-project-conclusion-05 – The Conclusion of the UUCP Mapping Project https://tools.ietf.o[...] 2007-08-25
_[18] 문서 Sender Rewriting Scheme
_[19] 서적 Sendmail – An Internetwork Mail Router https://docs.freebsd[...] University of California 2012-06-29
_[20] 논문 The Technical Development of Internet Email http://www.ir.bbn.co[...] IEEE Computer Society 2008-00-00
_[21] 웹사이트 Allowing Relaying in SMTP: A Survey http://www.imc.org/i[...] Internet Mail Consortium 2010-05-30
_[22] 웹아카이브 Allowing Relaying in SMTP: A Series of Surveys http://www.imc.org/u[...] Internet Mail Consortium 2010-05-30
_[23] 웹아카이브 In Unix, what is an open mail relay? - Knowledge Base http://kb.iu.edu/dat[...] 2021-03-15
_[24] 웹아카이브 The MAIL, RCPT, and DATA verbs http://cr.yp.to/smtp[...] 2014-02-22
_[25] IETF RFC Simple Mail Transfer Protocol, Section 7.2
_[26] 보도자료 Message Systems Introduces Latest Version Of Momentum With New API-Driven Capabilities https://www.prnewswi[...] Message Systems 2020-07-19
_[27] 잡지 ISPs Pitch In to Stop Spam http://www.pcworld.c[...] 2016-01-18
_[28] IETF RFC
_[29] IETF RFC Simple Mail Transfer Protocol 2010-06-07
_[30] IETF RFC SMTP Service Extensions Internet Engineering Task Force 1995-11-00
_[31] 웹사이트 MAIL Parameters https://www.iana.org[...] IANA 2019-05-28
_[32] 문서
_[33] 메일링리스트 Chinese email address http://www.ietf.org/[...] Internet Engineering Task Force 2016-05-24
_[34] 웹사이트 SMTP Service Extension Parameters https://www.iana.org[...] IANA 2013-11-05
_[35] 웹아카이브 James Server - ChangeLog http://james.apache.[...] James.apache.org 2013-07-17
_[36] 문서 8BITMIME service advertised in response to EHLO on gmail-smtp-in.l.google.com port 25 2011-11-23
_[37] 웹사이트 Qmail bugs and wishlist https://archive.toda[...] 2013-07-17
_[38] 웹사이트 The 8BITMIME extension http://cr.yp.to/smtp[...] 2013-07-17
_[39] IETF SMTP Service Extension for 8-bit MIME Transport 2011-03-01
_[40] 웹사이트 Postfix SMTPUTF8 support is enabled by default http://www.postfix.o[...] 2015-02-08
_[41] 보도자료 Message Systems Introduces Latest Version Of Momentum With New API-Driven Capabilities http://www.prnewswir[...] 2020-09-17
_[42] 웹사이트 Version 6.2 Revision History https://communigate.[...] 2020-09-17
_[43] 메일링리스트 New releases of Courier packages https://sourceforge.[...] 2018-09-18
_[44] 웹사이트 Halon MTA changelog https://github.com/h[...] 2021-11-09
_[45] 웹사이트 MS-OXSMTP: Simple Mail Transfer Protocol (SMTP) Extensions https://interoperabi[...] 2020-09-17
_[46] 웹사이트 EAI Readiness in TLDs https://uasg.tech/wp[...] 2020-09-17
_[47] 웹사이트 Communications Messaging Server Release Notes https://docs.oracle.[...] 2020-09-17
_[48] 웹사이트 Introducing MTA Strict Transport Security (MTA-STS) Hardenize Blog https://www.hardeniz[...] 2019-04-25
_[49] 웹사이트 STARTTLS Everywhere https://starttls-eve[...] EFF 2021-12-04
_[50] 웹사이트 How SMTP DNS-based Authentication of Named Entities (DANE) secures email communications https://learn.micros[...] 2023-07-21
_[51] 웹사이트 Implementing Inbound SMTP DANE with DNSSEC for Exchange Online Mail Flow https://techcommunit[...] 2024-03-05
_[52] 웹사이트 Gmail becomes first major email provider to support MTA-STS and TLS Reporting https://www.zdnet.co[...] 2019-04-25
_[53] 웹사이트 Message Non Compliant with RFC 5322 https://support.goog[...] 2021-01-20
_[54] 웹사이트 Message could not be delivered. Please ensure the message is RFC 5322 compliant. https://answers.micr[...] 2021-01-20
_[55] 웹사이트 Why are the emails sent to Microsoft Account rejected for policy reasons? https://answers.micr[...] 2021-01-20
_[56] 서적 Simple Mail Transfer Protocol
_[57] 서적 Simple Mail Transfer Protocol
_[58] 웹사이트 動作を確認したSMTP認証/Submissionポート対応メールソフト一覧 https://www.iij.ad.j[...] 2019-08-12

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com